Subject: Welcome

From: Choon Lee <[email-masked]>
Date: Wed, 7 Jul 1993 13:15:02 -0700

Welcome to the loop prevention siglet.
As the name suggests, this siglet will be discussing issue(s) regarding
loop detection and prevention. Just a note here that it is not the intention
of this siglet to solve other problems that ethernet may have.

As a start, I've attempted to pick out some discussions that touched on the topic 
from the dlsw maillogs.

I hope that we will get a lot of support/discussions in this siglet such that we
would have made substantial progress in time for the next aiw meeting.

/choon lee

>> >From [email-masked]  Mon Jun 14 12:31:32 1993
>> Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [128.185.123.16] with SMTP
>> 	id AA108635 (for [email-masked], from [email-masked]/[email-masked]); Mon, 14 Jun 93 12:31:32 -0400
>> Received: from danno.proteon.com by monk.proteon.com (5.65/1.8)
>> 	id AA00620; Fri, 11 Jun 93 17:30:43 -0400
>> Received: by danno.proteon.com (4.1/SMI-4.1)
>> 	id AA08669; Fri, 11 Jun 93 17:28:05 EDT
>> Date: Fri, 11 Jun 93 17:28:05 EDT
>> From: [email-masked] (Himanshu C. Shah)
>> Message-Id: <[email-masked]>
>> To: [email-masked]
>> Subject: DLSw RFC related questions
>> Status: RO
>> 
>> 

[ .. much deleted ]

>> 
>> 8) What about transparent bridging support? As we know there is no standard
>> for Source Route Bridging. There is a draft standard IEEE802.5M/D7 for SRT
>> which is now close to become a standard and will be added as an 
>> addendum to IEEE802.1d standard. According to this standard, a token ring
>> port in a bridge will support both Source route bridge as well as 
>> transparent bridging. If an end station uses A & C bit setting on a
>> transparent test frame to decide whether the destination is locally present
>> on the ring or not, this will present a problem for Data link Switches in SRT 
>> bridged LAN. In order to prevent loop through the DLS cloud, Spanning Tree
>> Protocol becomes a necessity. 
>> 
>> We must have a code point in the control header to pass Hello BPDUs around
>> to form a spanning tree and break the loops.
>> 
>> There is also another standard evolving for end stations, called 
>> Route Determination Entity (RDE), to select a suitable frame format in 
>> different bridged environment. RDE defaults to transparent bridged 
>> environment.
>> 
>> Himanshu
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> >From [email-masked]  Tue Jun 15 18:27:30 1993
>> Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [129.213.128.4] with SMTP
>> 	id AA112137 (for [email-masked], from [email-masked]/[email-masked]); Tue, 15 Jun 93 18:27:30 -0400
>> Received: from kinabalu.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA27252
>>   (5.65c/IDA-1.4.4nsd for <[email-masked]>); Tue, 15 Jun 1993 15:32:16 -0700
>> Received: by kinabalu.NSD.3Com.COM id AA02595
>>   (5.65c/IDA-1.4.4-910725); Tue, 15 Jun 1993 15:32:15 -0700
>> Date: Tue, 15 Jun 1993 15:32:15 -0700
>> From: Choon Lee <[email-masked]>
>> Message-Id: <[email-masked]>
>> To: [email-masked], [email-masked]
>> Subject: Re:  Updated RFC
>> Status: RO
>> 
>> 
>> >> 
>> >> > Does it (or the latest release of DLSw) contains spanning tree support?
>> >> 
>> >> Unfortunately, no - we have not implemented spanning tree support.  That
>> >> is a product limitation not a DLSw limitation.
>> >> 
>> >> David Miller
>> >> 
>> 
>> I do not agree that we can leave out spanning tree when we talk about
>> Ethernet (and for that matter, non-source routing in token ring).
>> 
>> Without spanning tree (or an alternate method of loop prevention), the
>> attractiveness of DLSw in a real world network is greatly curtailed. 
>> 
>> /choon lee
>> 
>> 

>> 
>> >From [email-masked]  Fri Jun 25 14:48:13 1993
>> Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [192.32.253.3] with SMTP
>> 	id AA131063 (for [email-masked], from [email-masked]/[email-masked]); Fri, 25 Jun 93 14:48:13 -0400
>> Received: from pandita.wellfleet (pandita.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1)
>> 	id AA24579; Fri, 25 Jun 93 14:49:14 EDT
>> Received: by pandita.wellfleet (4.1/SMI-4.1)
>> 	id AA01201; Fri, 25 Jun 93 14:54:22 EDT
>> Date: Fri, 25 Jun 93 14:54:22 EDT
>> From: [email-masked] (Scott Barvick)
>> Message-Id: <[email-masked]>
>> To: [email-masked]
>> Subject: RE: general concerns cont.
>> Status: RO
>> 
>> I agree with Larry's issues and most of Himanshu's responses
>> except for the configuration aspects and the looping ring numbers.
>> 
>> 1) Configuration:  DLS does not require both partners to be configured
>> for each other.  In the client server network, if all of the clients
>> are configured with the single server DLS IP address and the server DLS is
>> able to accept connections from unconfigured peers, then the server DLS can
>> wait for TCP connections from the client switches.  
>> 
>> Nonetheless, some type of discovery would be very useful.
>> 
>> 
>> 2) Looping SR explorers.  While configuring all DLS switches with
>> the same virtual ring number eliminates looping through the DLS
>> backbone, a backup SR bridge connection which connects regions also
>> connected by DLS switches will result in looping of the explorers once
>> more within the source routed LAN portion of the network.  Painful
>> experience has shown this to hang some end stations.  The RFC does say
>> not to establish TCP connections between switches connected to the same
>> bridged LAN - for efficiency and (very likely) this reason.  
>> 
>> Scott
>>  
>> 
>> 
>> >From [email-masked]  Mon Jun 28 09:46:54 1993
>> Received: by ibmstandards.cary.ibm.com (5.61-AIX-1.2/1.0) from [192.239.48.4] with SMTP
>> 	id AA135914 (for [email-masked], from [email-masked]/[email-masked]); Mon, 28 Jun 93 09:46:54 -0400
>> Message-Id: <[email-masked]>
>> Received: from RALVM29 by vnet.IBM.COM (IBM VM SMTP V2R2) with BSMTP id 6710;
>>    Mon, 28 Jun 93 09:50:43 EDT
>> Date: Mon, 28 Jun 93 09:47:51 EDT
>> From: [email-masked]
>> To: [email-masked]
>> Subject:  DLSw common ring number requirement
>> Status: RO
>> 
>> I believe that the requirement that switches use a common DLSw ring
>> number need apply only to routers connected to the same bridged
>> lan.  Since DLSw does not have an intermediate forwarding function
>> on top of TCP, this "parallel bridging path" configuration is the
>> only way to get a loop and thus the only one to need a common ring
>> number.  I agree with Scott Barvick that this undesirable configuration
>> can result in a frame copy going once around the loop in each direction
>> if the switches on the same LAN are directly TCP connected.
>> 
>> I don't see a problem with two routers across the WAN from each other
>> having distinct virtual ring numbers.  Each end station sees the other
>> end station as being on a different LAN segment (i.e., the virtual
>> ring of the near side router).  The entire end station-to-end station
>> RIF is never constructed, which has the advantage of relieving the 7-hop
>> limitation of pre-SRT bridges.  I do believe that the LF bits must be
>> propagated end-to-end, however, so an end station can know not to
>> construct frames which exceed the max of an SR bridge on the far side
>> of the WAN.
>> 
>> Peter Gayek
>> 
>> 
>>